The Radio Resource Control (RRC) protocol in the 3GPP Long Term Evolution (LTE), also referred to as Evolved UTRAN (E-UTRAN), is the signaling protocol for configuring and re-configuring the radio interface configuration of User Equipments (UEs), also called mobile terminals. The protocol is disclosed in the technical specification document 3GPP TS 36.331.
The first release, Rel-8, of RRC (described in 3GPP TS 36.331) of LTE deploys a solution where fields in Information Elements (IEs) can be omitted from a message. An IE consists of fields. Each field comprises individual content or a further IE which in turn comprises fields or further IE. In addition one message comprises a plurality of IEs as illustrated in FIG. 1. In the technical specification document 3GPP TS 36.331 the IE and the field are defined as follows:
Information element: A structural element containing a single or multiple fields is referred as information element.
Field: The individual contents of an information element are referred as fields.
The use of the fields in the IEs may be optional. If a field in an IE is optional, the UE behavior is typically specified for the case where that field is absent. One motivation for defining optional fields in messages is to reduce or minimize the size of the signaling messages. A typical situation is the case when only parts of the User Equipment (UE) configuration are changed with a message whereas most of the UE configuration remains unchanged. Thus, it is often specified that a terminal shall continue with a specific function when the related field, which is optional in the message in question, is not present in a received message.
An example of optional field is illustrated below where an IE comprising a plurality fields is disclosed. The Channel Quality Indication (CQI) is configured with an Information Element called CQI-ReportConfig:
CQI-ReportConfig ::= SEQUENCE { cqi-ReportModeAperiodicENUMERATED {   rm12,rm20,rm22,rm30,rm31,    spare3,spare2,spare1} OPTIONAL -- Need OR nomPDSCH-RS-EPRE-Offset INTEGER (−1 . . . 6), cqi-ReportPeriodic CQI-ReportPeriodic OPTIONAL - Need ON}
Within this IE, both cqi_ReportModeAperiodic and cqi-ReportPeriodic are both optional fields, which is indicated with the syntax OPTIONAL above.
Therefore the UE behavior has to be specified when the optional parameters are absent. This can be done by using the tags “Need OR” and “Need ON”, respectively, which specifies the UE behavior when the optional parameters are not present. Need OR means that in case the information element is absent from a message, then the UE should stop using/discontinue or delete any existing configuration or values that would otherwise be configured if the information element would be present. In contrast, with the tag Need ON, the absence of the information element means that the UE should continue to use the already existing values and associated functionality. Hereafter, the behaviour where the UE should keep the configuration and related functionality without changing any parameters at times when an optional field is missing, is called “Optional Continue”.
Also other conditions and functional behavior may be explicitly specified in the specification procedures, i.e. different behaviors can be specified when an optional field is missing from a relevant message. For instance, also the IE CQI-ReportConfig is OPTIONAL in the IE PhysicalConfigDedicated. The IE PhysicalConfigDedicated is in turn “Optional Continue” in IE RadioResourceConfigDedicated, which in turn is optional in the message RRCConnectionReconfiguration. RRCConnectionReconfiguration is the message sent from EUTRAN to a UE for configuring and re-configuring functionality and related parameters in a UE. Thus, the solution for “Optional Continue” is used in the specification such that only those fields of relevance for the desired reconfiguration need to be included in the IE of the message.
The aforementioned solution using “optional continue” is used, e.g., in intra-LTE mobility. This is also illustrated in FIG. 2. In the following, for the case that a handover of a mobile terminal occurs from a first cell to a second cell, the first cell is denoted the Source Cell and the second cell is denoted the Target Cell. Similarly, where cells are controlled by different base-stations, this is denoted Source eNB and Target eNB, respectively. The eNBs are also referred to as base stations in this specification. The desire is to exchange only small messages between the UE and eNBs at handover. It can be assumed that many of the functionalities used in the Source Cell will remain unchanged in the Target Cell, and it would therefore be unnecessary to reconfigure all functionalities in the Target Cell.
Hence if the handover occurs between different eNBs, i.e. from a Source eNB to a Target eNB, the Source eNB sends the full UE configuration to the Target eNB at the preparation for the handover. The HANDOVER REQUEST message from the source eNB contains the RRC Context which includes the RRC HandoverPreparationInformation message as defined in 3GPP TS 36.331. The Target eNB may now, after decoding the received Access Stratum Context, decide which parts of the UE configuration it finds acceptable without change, and which parts should be reconfigured. For example, it is likely that nearby base-stations operated by the same operator and possibly manufactured by a single vendor prefer the same parameters that describe periodic CQI reporting. In such a case, there is no need for the Target eNB to send any updated configuration to the UE, since the Target readily accepts this part of the present UE configuration. However, if it happens that the Target eNB implements a e.g. a different Random Access configuration compared to Source eNB, it may happen that Target needs to update some Random Access parameters of relevance in the UE.
Subsequently, the Target eNB sends in the HANDOVER REQUEST ACKNOWLEDGE a “Handover Command” using a RRCConnectionReconfiguration message, which now may include fields that are “Optional Continue”, such that the UE keeps its current configurations to these parts if the corresponding fields are missing. It is thus possible to create a flexible protocol that allows for reconfigurations, but where small message sizes can be provided in case only specific parts of the configurable parts are reconfigured. Specifically, the solution is also applied at handover.
3GPP protocols are published in different releases. Functionality can be changed between protocol releases and it is typical that new, enhanced functionality is added into new protocol releases. For instance, after that Rel-8 of the E-UTRAN protocols is considered to be functionally stable, future changes will be added into Rel-9, Rel-10, and so on.
Typically, it is not possible to add non-backwards compatible functionality and protocol extensions to a stable protocol, since that could result in malfunctioning of UEs and nodes already out in the field that does not support such amendments. RRC is implemented using Abstract Syntax Notation One (ASN.1) by which messages can be extended in new releases. Such extensions typically include parameters of relevance for the functionality that is added in the later release. Both “non-critical” and “critical” extensions can be added.
A critical extension implies that a receiver of an earlier release of such an extension will not understand the content of the message. For example, if a Rel-9 eNB sends a Rel-9 message to a Rel-8 UE, where the message includes a critical extension, then the UE may fail to decode the message.
A non-critical extension has the characteristic that a receiver of an earlier release may ignore the non-critical extension, but the receiver may still successfully decode the parts of the message that complies with the earlier release. For example, if a Rel-9 eNB would send a message to a Rel-8 UE, where the message includes a non-critical extension, then the UE may still decode the parts of the message that follows the Rel-8 syntax. RRC Rel-8 includes placeholders in the messages and relevant IEs for such non-critical extensions. This has been done in order to prepare for the extendibility of the RRC protocol.
It has been noted that the “optional continue” can cause a problem at handover for those cases where Source eNB and Target eNB implement different protocol release versions. Suppose that the Target eNB implements a protocol and functionality specified in Rel-8. Assume further that the Source eNB implements a later release with additional functionality, e.g. Rel-9. It is further assumed that the added functionality in the Rel-9 RRC protocol is added by using protocol extensions and that the UE is configured with the features associated with the new Rel-9 features. One problem related to this scenario occurs if the aforementioned new information elements or fields in a later release (e.g. Rel-9) are added using critical extensions, i.e. the source eNB sends a Rel-9 HandoverPreparationInformation message to the Target eNB, since the exemplified Rel-8 Target eNB may fail to decode the Access Stratum Context message received in the handover preparation message. In such a case, the Target eNB may have to send a complete re-configuration message to the UE in the “handover command”, as the Target is unable to decode the configuration of the UE, i.e. Target eNB does not know what configuration the UE currently has. Thus, “Optional Continue” would be impossible for the eNB of the previous release, and large handover messages would be needed. Another related problem occurs if the aforementioned new information elements or fields in a later release (e.g. Rel-9) are added using non-critical extensions. In this case, the exemplified Rel-8 Target eNB supporting a previous release may successfully decode the parameters included in the previous release. However, the Target eNB will not understand the encoding of the later release fields, and it would have to ignore those fields. Thus, those fields would not be present in the “handover command”, since the Target eNB would not know how to encode such fields.
The problem occurs in the later-release (e.g. Rel-9) UE that receives the “handover command”. If the principle of “Optional Continue” was to be implemented for the new fields, then the UE should continue using the configured later-release features after handover without any change. However, in the example, the non-presence of these new fields was due to the fact that the Target eNB did not comprehend those fields, and the Target eNB does clearly not support the later release protocol features. Thus, a mismatch could occur, where the UE continues using functionality that the Target eNB does not implement, and severe protocol and functional errors could occur, since the communicating peer entities (UE and Target eNB) would assume different configurations.